feat(client): support Expect: 100-continue#3472
feat(client): support Expect: 100-continue#3472iasoon wants to merge 1 commit intohyperium:masterfrom
Conversation
This patch modifies hyper client to behave correctly when the `Expect: 100-continue` header is set on a request. The request body will now only be sent once a 100 Continue response is receved from the server.
|
Thanks for the PR and taking this on! One thing I was wondering about is how would someone choose to wait only a certain amount of time for the server to respond? We could add another timeout into the connection state, but if it's not super hard to do outside, I think that's preferable. A different way of doing this would be to make the I'm not sure which is best, at the moment. |
seanmonstar
added
the
S-waiting-on-author
|
FWIW - I hit this bug recently as well and was just about to file something. Thanks @iasoon for proposing a fix. I work on some storage services where this feature is key to avoiding sending large amounts of data that would otherwise be rejected anyway so this is super high value to my users and my service's scalability. I'm glad to test patches if it helps validate things.
I actually started going down this route as it seemed like a way to avoid requiring patching hyper but ended up having to give up as there was no good way to signal the continue came through. However, after thinking about what this would look like my 2c is that the connection is the right place to do this as it's part of the protocol and not a property of the body. If you wire up the continue logic in the body's poll method, for example, then failure to choose the right body implementation that can pause results in not speaking the protocol correctly which seems error prone. |
3 participants
This patch modifies hyper clients to respect the
Expect: 100-Continueheader.When the header is present on a request, the client will not send the request body
until the
100 Continueinformational response is received from the server.Related issue: #2565
The implementation follows the existing
on_informationalcallback mechanism,threading the connection state through to the reponse header parsing.
This seems like the most straightforward modification to get
Expect: 100-Continuesupport, but happy to discuss alternatives.